Thin clients are generally defined as clients that perform little or no local data processing. Such thin clients may rely on central computer such as a server to execute applications. The clients and the server are coupled to one another via a network. The server generally provides audio and video data over the network to the thin client (e.g., a desktop device). The desktop device may play back the audio data or display the video data as such data is received from the server.
Depending on the application, a transmission speed of a network connection between a thin client and a server may vary. For example, the transmission speed may vary from 300 Kbits per second on a Digital Subscriber Line (DSL) line to around 100 Mbits per second in a Local Area Network (LAN). Higher speed network connections may enable the thin client to perform at a higher performance level assuming the network connection is a bottle neck instead of processing capability at the central computer. In general, since thin clients depend heavily on the throughput of a communication link with the server, the communication link needs to be used as efficiently as possible particularly as it relates to the amount of available bandwidth for transmitting audio and video data.
Characteristics of data sent to a thin client (e.g., desktop unit) may be different than most network traffic (e.g., files or web pages) which is transmitted in accordance with an acknowledgment based protocol such as TCP/IP (Transmission Control Protocol/Internet Protocol). One potentially significant property associated with file transfer and web page accesses is that all of the data typically should be reliably delivered reliably and correctly ordered to the application attempting to access such data. Even the loss of a single byte of data may be unacceptable. The standard TCP, on top of the IP (such as TCP/IP), supports data transmissions with the desirable property that lost data packets are retransmitted until all data is properly received at a receiver. For example, if data is lost during transmission, the TCP protocol causes retransmission of lost data until the sender acknowledges receipt of the data. Delays and throttling mechanisms are sometimes implemented in TCP sending and retransmission algorithms to make efficient use of the available bandwidth and to avoid causing over-congestion in the network.
In a thin client environment, time is generally of the essence. Audio data in a thin client application should be received at the thin client at the right time to drive an output device (e.g., such as a speaker). If not, the audio output from the speaker may be of poor quality. A smooth audio output may be achieved through the use of buffering at the thin client to allow for time variance of receiving audio packets. Unlike a Transmission Control Protocol (TCP), loss of an audio packet in the network does not cause the sender to retransmit that particular data. This condition exists largely because real time data that is received too late in time is generally useless for playback purposes. One network protocol that may accommodate data transmission between one or more thin clients and the server is the UDP over the Internet Protocol (IP). UDP, while beneficial, allows an unreliable transmission of packets. Accordingly, a higher level protocol may be needed to recover lost or mis-ordered packets.